RuntimeError: Cannot enter into task #22
Comments
|
@maartenbreddels did you find any solution to this problem? I can actually reproduce the error, but it is unclear what is causing it. |
|
I have the same issue, but with another task: |
|
No, I don't see the error anymore, so I'm clueless. |
This error is indicative of an unpatched Task. It could be similar to the unpatched Future from #23, were it gets imported before nest_asyncio has patched If possible, do the import and application of nest_asyncio before importing other modules. |
|
Same error with I am patching loop before I start it by the way. |
|
For my understanding (and possibly others), this simple script will trigger this exception: import asyncio
import nest_asyncio
async def task1():
print("task1 before")
await asyncio.sleep(0.4)
print("task1 after")
async def task2():
print("task2 before")
await asyncio.sleep(0.4)
print("task2 after")
async def main():
print("main: start")
task = asyncio.create_task(task1())
nest_asyncio.apply()
asyncio.run(task2())
print("main: end")
await task
asyncio.run(main())Which gives the following output: Note that this confirms what @erdewit was saying, it will be triggered when asyncio machinery wants to resume a task that is unpatched (i.e. created before .apply() was called). Hopefully, this will help to debug similar issues. |
This is a fix for jupyter/notebook#6164 We are only applying `nest_asyncio` when `run_sync` has been called which means there could be tasks queued that are unpatched e.g. from the original issue: ``` <Task pending coro=<HTTP1ServerConnection._server_request_loop() running at /apps/python3/lib/python3.7/site-packages/tornado/http1connection.py:823> ``` which originates from Tornado. A similar issue was reported in `nest-asyncio`: erdewit/nest_asyncio#22 where the solution is to call `apply` on import so that unpatched tasks do not get created.
This is a fix for jupyter#6164 `nest_asyncio` must be applied before any async tasks have been created otherwise there could be tasks queued that are unpatched, and thus do not respect nested loops. An example of an unpatched task can be seen in the original issue: ``` <Task pending coro=<HTTP1ServerConnection._server_request_loop() running at /apps/python3/lib/python3.7/site-packages/tornado/http1connection.py:823> ``` which originates from Tornado. A similar issue was reported in `nest-asyncio`: erdewit/nest_asyncio#22 where the solution is to call `apply` on import so that unpatched tasks do not get created.
This is a fix for jupyter#6164 `nest_asyncio` must be applied before any async tasks have been created otherwise there could be tasks queued that are unpatched, and thus do not respect nested loops. An example of an unpatched task can be seen in the original issue: ``` <Task pending coro=<HTTP1ServerConnection._server_request_loop() running at /apps/python3/lib/python3.7/site-packages/tornado/http1connection.py:823> ``` which originates from Tornado. A similar issue was reported in `nest-asyncio`: erdewit/nest_asyncio#22 where the solution is to call `apply` on import so that unpatched tasks do not get created.
This is a fix for jupyter/notebook#6164 `nest_asyncio` must be applied before any async tasks have been created otherwise there could be tasks queued that are unpatched, and thus do not respect nested loops. An example of an unpatched task can be seen in the original issue: ``` <Task pending coro=<HTTP1ServerConnection._server_request_loop() running at /apps/python3/lib/python3.7/site-packages/tornado/http1connection.py:823> ``` which originates from Tornado. A similar issue was reported in `nest-asyncio`: erdewit/nest_asyncio#22 where the solution is to call `apply` on import so that unpatched tasks do not get created.
As of [nest_asyncio 1.5.2](erdewit/nest_asyncio@1856573), we can initialize nest_asyncio inside running loops (e.g. Jupyter). If nest_asyncio is initialized after even one task is created, [users receive inscrutable errors](https://github.com/erdewit/nest_asyncio/issues/22\#issuecomment-874710264). This error happened during the QoB workshop I ran. This change takes advantage of nest_asyncio 1.5.2 to initialize nest_asyncio before *everything*, thus ensuring it can completely patch the event loop. You can reproduce the error yourself by running `python3 -c "import hail as hl; hl.init(billing_project=\"not-a-real-billing-project\")"` repeatedly in a terminal. I encounter the error ~50% of the time. With this change, I did not see the error after 5 invocations of that command.
|
FWIW, I was encountering this issue when initializing asyncio after a loop was already running but before I created any tasks. Since 1.5.2, you can And I don't see this error. |
* [qob] fix use of nest_asycnio As of [nest_asyncio 1.5.2](erdewit/nest_asyncio@1856573), we can initialize nest_asyncio inside running loops (e.g. Jupyter). If nest_asyncio is initialized after even one task is created, [users receive inscrutable errors](https://github.com/erdewit/nest_asyncio/issues/22\#issuecomment-874710264). This error happened during the QoB workshop I ran. This change takes advantage of nest_asyncio 1.5.2 to initialize nest_asyncio before *everything*, thus ensuring it can completely patch the event loop. You can reproduce the error yourself by running `python3 -c "import hail as hl; hl.init(billing_project=\"not-a-real-billing-project\")"` repeatedly in a terminal. I encounter the error ~50% of the time. With this change, I did not see the error after 5 invocations of that command. * fix lint
|
@erdewit I've been looking into this and I think the problem can be solved by protecting Lines 117 to 120 in 1ddc550 this is the approach i have taken here which seems to work: https://github.com/vyperlang/titanoboa/blob/1979a4d9c57eab7b27161a857ad56dd90f7f5728/boa/integrations/jupyter.py#L159-L161 |
|
With the implementation of @charles-cooper's idea in v1.6.0 this bug should be fixed. It can now run unpatched tasks. |
Hi,
thanks for this amazing package, this was for me the reason to adopt asyncio (otherwise the maintenance burden was too high).
I sometimes see this error in CI systems, and have trouble reproducing it locally:
I wonder if you have any idea what can cause this so I can try to reproduce it and open a proper issue (or fix it).
cheers,
Maarten
The text was updated successfully, but these errors were encountered: